During the operational use of software, database inconsistencies may result from program errors (e.g., database software errors), computer outages, and incorrect or incomplete data entries. Further, for networked computers, a data transfer to a database on a networked computer might be disrupted by the network as a result of a network outage, for example. In such an instance, the data transfer may be incomplete, and severe data inconsistencies might occur because related data is spread over various databases.
In accounting and financial software applications, for example, customer details may be stored in a first database table, and corresponding bills or purchase orders may be stored in a second database table. In such instances, the bills or purchase orders in the second database table may be associated with customers having their contact information stored in the first database table. Due to a system failure, data of a certain customer may be deleted from the first database, while a purchase order related to that customer may exist in the second database. Such a data inconsistency may only become evident at the time of delivery or shipping of the order, when a recipient cannot be named and associated with the order, since no customer data is available for the recipient.
Once a customer identifies a problem associated with a database inconsistency, the customer may rely on specialized companies to develop software tools for each database inconsistency problem. For example, these software tools may search for a specific kind of inconsistency problem and correct this inconsistency problem in the customer database or databases.
For example, the customer may resolve an identified database inconsistency problem using specialized software obtained through a “pull” approach, i.e., a user detects an inconsistency problem in a database and then checks with a software maintenance provider for available programs to identify and correct the detected inconsistency problem. However, unless the user discovers the problem, no action will be taken and the inconsistency remains, along with its potentially harmful consequences.
Further, in such a pull approach, an individual software tool may need to be designed for each customer. For example, a direct, universal distribution of particular software tool to customers having a similar inconsistency problem may not be possible, since certain types of inconsistencies are interdependent and some corrections might not be performable until another inconsistency is solved. Therefore, such software tools might have to be executed by special experts that are familiar with the interdependencies in order to avoid misuse after having considered the potential impact of a correction to the customer system.
In view of the foregoing, there is a need for improved systems and methods for correcting data inconsistencies within databases and/or data repositories.